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(54) System and method for executing verifiable programs with facility for using non-verifiable 
programs from trusted sources 



(57) A computer system includes a program execut- 
er that executes verifiable architecture neutral programs 
and a class loader that prohibits the loading and execu- 
tion of non-verifiable programs unless (A) the non-veri- 
fiable program resides in a trusted repository of such 
programs, or (B) the non-verifiable program is indirectly 
verifiable by way of a digital signature on the non-veri- 
fiable program that proves the program was produced 
by a trusted source. In the preferred embodiment, veri- 
fiable architecture neutral programs are Java bytecode 
programs whose integrity is verified using a Java byte- 
code program verifier. The non-verifiable programs are 
generally architecture specific compiled programs gen- 
erated with the assistance of a compiler. Each architec- 
ture specific program typically includes two signatures, 
including one by the compiling party and one by the 



compiler. Each digital signature includes a signing party 
identifier and an encrypted message. The encrypted 
message includes a message generated by a prede- 
fined procedure, and is encrypted using a private en- 
cryption key associated with the signing party. A digital 
signature verifier used by the class loader includes logic 
for processing each digital signature by obtaining a pub- 
lic key associated with the signing party, decrypting the 
encrypted message of the digital signature with that 
public key so as generate a decrypted message, gen- 
erating a test message by executing the predefined pro- 
cedure on the architecture specific program associated 
with the digital signature, comparing the test message 
with the decrypted message, and issuing a failure signal 
if the decrypted message digest and test message di- 
gest do not match. 
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in J^ PreSent inVenti ° n re,a,eS 9enera " y l ° dis,ribu, ed computer systems, and particularly to a system and method 



BACKGROUND OF THE INVENTION 



of computer platforms using a number of different computer architectures executed on a variety 

nrnnL™ e , rm h " arChi,eC, r SpedfiC " i8 d6fined ,0r ,he ^P 05 ™ of this document to refer to requirement that certain 

P p og 9 ;: :i:zZoTe sssn r plat,orms usin9 a sin9ie compu,er architecture - f °^ = S^s 

rnmnfZ ? hT , 1he / 80486 assemble '- language can only be executed on computers using the IBM PC compatible 
computer architecture (as well as in other computers that contains IBM PC compatible computer emulators? 

P^= 

verifier determines whether the program conforms to predefined integrity criteria. B%5££^t^ZZ 

tlnTJr USa9 H S r , eSt : iCti ° nS th3t enSUfe ,hat JaVa by1ecode ? r °9 rams ca ™°» overflow or 1 mS^S!^^ 
£2 nl 9 *"* ^ that a " Pr ° 9ram instruction * data of known data typj^j£?722 

ZspZraZc^cSZ eXer tyPiC ? 2 5 10 5 tim8S 85 S ' OW 35 the eQ - uivalent arcLctureVecIc programs 

* S^Jb^ that S ° me US6rS Wi " reQUire " inSiSt UP ° n ,he abilit V «? «• e^ivalen, programs compile Mn an 
nrohfn 0 ^., 16 ' 5 that f ° mpHe an ANPr °9 ram int ° an equivalent ASProgram can be written. However they mav be 

„. th Alt i hou 9 | ] i c °" 1 P ifa,ion of ANPrograms by a third party is possible, such compilations require that the third oartv be 
authenticated. That is, i, must be possible to verify from the information in the compiled ASpS^^SSSiS 

was aeneL d U n " ^ * Sh ° U ' d a ' S ° b * P ° SSibte to -'henticate tha, S^iSSSSS 

^X ri T » 3 SPeC ' flC UUS,ed C ° mpiler And ' SinCe * e inte 9 ritv of the compiled ASProgram ShTesoecUo 

Twas compTed ^"^a ™*o*™ which it was compiled and the ASLanguage in which 



userlTa^pToa^m Lmn f h T"*" ™ ANPr °9 ram com P» r and compilation method that enables the 
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verifiable sources and compilation information so that essentially all legitimate tasks can be performed, while preventing 
from being called ASPrograms whose sources, compilation information, and integrity cannot be verified. 



SUMMARY OF THE INVENTION 

5 

In summary, the present invention is a program executerthat executes verifiable architecture neutral programs, 
and a class loader that prohibits the loading and execution of non-verifiable programs unless (A) the non-verifiable 
program resides in a trusted repository of such programs, or (B) the non-verifiable program is indirectly verifiable by 
way of a digital signature on the non-verifiable program that proves the program was produced by a trusted source. 
io in the preferred embodiment, each verifiable program is an architecture neutral program embodied in an object 

class having a digital signature that includes a message digest uniquely associated with that program. 

Non-verifiable programs are embodied in object classes that contain a keyword indicating that the program (called 
a method) is not a verifiable program. In the preferred embodiment the non-verifiable programs are generally archi- 
tecture specific compiled program generated with the assistance of a compiler. Each such object class includes: 

15 

the compiled, architecture specific code; 

if there is a corresponding architecture neutral program (which sometimes there is not), information identifying the 
corresponding architecture neutral program, including a copy of the message digest of the corresponding archi- 
tecture neutral program; 

20 . a digital signature by the trusted "compiling party- that generated the object class (e.g., by performing a compilation 
of a source program), signed using the compiling party's private encryption key; and . if the code in the object class 
was generated by a compiler, a digital signature by the compiler itself, signed using the compiler's private encryption 
key. 

2S a generally available, trusted repository of public encryption keys, sometimes called a naming service, holds the 

public keys for the compiler and the trusted compiling party Using these public encryption keys all recipients of the 
object classes having non-verifiable programs can decrypt the digital signatures in the object class to verify that the 
object class was created by a trusted party, to verify that the non-verifiable program code in the object class was 
generated by the indicated compiler (if any), and also to verify the identity of the corresponding architecture neutral 

30 program (if any). Optionally, when the non-verifiable program code in the object class has a corresponding verifiable 
program, the potential user of the object class can use the program verifier to verify the proper operation of the corre- 
sponding verifiable program prior to executing the non-verifiable program code in the object class. 

BRIEF DESCRIPTION OF THE DRAWINGS 

35 

Examples of the invention will now be described in conjunction with the drawings, in which:- 
Fig. 1 is a block diagram of a distributed computer system incorporating a preferred embodiment of the present 
invention. 

Fig. 2 depicts the structure of an architecture neutral program in accordance with a preferred embodiment of the 
40 present invention. 

Fig. 3 depicts the structure of a compiled, architecture specific, program generated in accordance with a preferred 
embodiment of the present invention. 

Fig. 4 depicts an object and associated object class in accordance with a preferred embodiment of the present 
invention. 

45 

DESCRIPTION OF THE PREFERRED EMBODIMENTS 



Referring to Fig. 1 , there is shown a computer network 100 having many client computers 102, a server computer 
104, and a trusted key repository 106. The client computers 102 are connected to each other and the server computer 
104 and the trusted key repository 106 via a network communications connection 108. The network communications 
connection may be a local or wide area network, the Internet, a combination of such networks, or some other type of 
network communications connection. 

While most of the client computers 102 are desktop computers, such as Sun workstations, IBM compatible com- 
puters, and Macintosh comput rs, virtually any type of comput r could be a client computer. Each of th s cli nt 
computers includes a CPU 110, a user interface 112, a memory 114, and a n twork communications interface 116. 
The network communications interface nables the client computers to communicat with each other, the serv r com- 
puter 104, and the trust d key repository 108 via the network communications connection 106. 

The memory 1 1 4 of each client computer 1 02 stores an operating system 11 8, a network communications manager 
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(architecture neutral program) executer 122, an ASProgram (architecture specific program) exe- 
TZ ,^ a T N r < !° 9ram -nlegrityverifier 126, an ANProgram compiling preparer 128, a signature geLatoM 30 a 

lose ,« "a i tru B ted oh T? ,lin9 in,0rma,i ° n (C ° mP,n,0) VSrifier 134 ' an ° bject class 136 • » -e address 

space 138, a trusted object class reposrtory 140, an untrusted object class repository 142. and lists 144 of know. 

Uuste comp.Hng I part.es and trusted compilers. The operating system is run on the CPU 110 and com roTs 

donates runn.ng the programs 120-136 on the CPU in response to commands issued by a user with £22^to 

The ANProgram executer 122 of each client computer 102 executes ANPrograms in the object classes stored in 
the trusted and untrusted object class reposrtories 140 and 142. Moreover, the ANPrograms are mitten n La^Lo- 

r amp ' Ch the ; Ser ^ eStabHSh Pred6fined inte9r ^ criteria ' such as sta <* and data uSJTnS^.™^ 
the ANPrograms will not perform illegal tasks. Thus, the integrity of the ANPrograms can be direct^ S S by the 

aIZ 9T Z: IS Venf,er 126 r° r ,0 6XeCU,i0n by dete ™™9 if the program satisfies the predeffned VS£ 
cntena. These ANPrograms are therefore considered integrity verifiable ANPrograms 

nJV^Zt 6 " 6 * embodiment L the inte 9nty verifiable ANPrograms are written in the Java bytecode language More- 
o^J Inn = . 9 T/ Xe H Uter 122 the ANPr °9 ram ™«™ 124 are respectively a Java bytecode pragram imer- 
22 hi, h Pr ° 9ram Veri ' i8r th8t res P ectiv «'y execute and verify the Java byVecode programs The 

Java bytecode verif.er and .nterpreter are products of Sun Microsystems Inc programs, i he 

» ea f c ' Hent COmputer 102 has an associated specific architecture for which programs may be written in 

a correspond,^ ASLanguage and executed by the ASProgram executer 1 22. The ASLanguage does not reqTe th * 
ASPrograms wntten in the ASLanguage sattefy the predefined integrity criteria of the mL&^*?2SI the 
i^t 9 P f ° rm J asks ,ha < cannot be P^med by the ANPrograms because they a^e not burdened by Te 

res nct.ons imposed by the predefined integrrty criteria of the ANLanguage. Unfortunately, however, this a"so means 

TXr^S^ 66 direC,,V V6rified ^ ^ ANPr ° 9ram in,69rity V6rffier 126 ™* are therefore c^sTd^d 
Nevertheless, as indicated earlier, an ANProgram runs less efficiently than the same program compiled in an 

Iv Z aqp ASLan9Ua9e assoc ' a,ed the user's client computer so the compiled ASProgram can be executed theTe 
by he ASProgram executer 124. Or, the user may wish to have the ANProgram compiled for the ASLanquaqes asso 

^^^STi'TT! the compiled ASPrograms are 9 ° ina ,o be dis,ribu,ed and 

gram executers 124 of other client computers. 
Preparing an Architecture Neutral Program for Compiling 

Referring to Figs. 1 and 2, when an originating party (OrigParty) wishes to have an ANProgram 200 comoiled bv 

oZ7rZ C ^™ 'h 4 ' ? ° ri9Par,y iSSU6S 3 COmmand WKh the USer interface 112 10 invoke^AN^am com 
piling preparer 128 and .nstruct it to prepare the ANProgram for compiling. The ANProgram may be in an ctoiecl cteTs 

I" ° ne ,? ,r " StSd ° r Un,rUS,Sd ° bjeCt C,aSS "^nes 140 or 142. Table 1 contai s a ^ps^aocode 
representation of the procedure used by the ANProgram compiling preparer 128 to prepare the ANProaram^nm 

wh7e b ;c he ^ 

While the pseudocode employed here has been invented solely for the purposes of this description ? is ZiqnWd to 
be easily understandable by any computer programmer skilled in the art aesigned to 

Referring to Figs. 1 and 2 and Table 1, the ANProgram compiling preparer 12B first calls the ANProgram intearitv 
Zu" rfr^* 8 " t0 ,he in,e9rity ° f the ANP '°9ram code 202 of the ANProgram 20 ?h sTs done 7o 
make sure that the ANProgram code satisfies the predefined integrity criteria of the ANLanguage prior to being sen° 
AN Prnnra^ TT 1 °t ** C ° mpi,ing - " the ANPro 9'am code does not satisfy the predeLd integntj Sa t h e 
Z™Z Z!n T V Bt b8Ck 3 ,ail6d reSUlt ,0 the ANPro 9^m compi.ing preparer. In response me AN 
ca°ng L P 9 ^ COmpi ' in9 preparation praced "e and generates an appropriate message indi- 

verifleM2r/ e nHr^ Pr ° 9ram w COde , 202 ^ ^ the predefined int egrity criteria, then the ANProgram integrity 
then- llT t 3 PaSSSd rSSU,t t0 ANPr °9 ram compiling preparer 1 28. The ANProgram compiling prepared 
210 , ha In ^' 9natU f re generator 1 30 and instructs it to generate the OrigPart/s digrta. signature (Digita.Signatu^p 
210 that can be venf.ed to ensure that the ANProgram 200 was generated by the trusted OrigParty The siqSe 

202 t:l 9 :zt the D ? teis rr e - by first 9enera,in9 a m ^ ( m Dop) 2 , 2 ofS^s 

f und i 7 K C ° mp u U " 9 8 haSh ,UnCti ° n ' Ha^^^ionop, on the data bits of the ANProgram code Th hash 
2££T,h H 8 "^ e,t t h6r 3 Predet6rmined hash or one selected by the OrigParty'por purpos s of this 

document, th HashFunct,on OP corresponds to the OrigParty since K was used for the Digteislgnaturej of the Orig- 

The signature generator 130 then encrypts the generated massage digest (MD OP ) 212 and the ID of the Hash- 
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Function OP (HashFunction OP ID) 214 with th private encryption key of the OrigParty (OrigParty's PrivateKey). The 
signature generator then adds the OrigParty's ID 216 in clear text at the end of the encrypted items 212 and 214 to 
form the DigitalSignature OP . The OrigParty's PrivateKey and ID are provided by the OrigParty with the user interface 
112. ; 

s After the DigitalSignature op 21 0 is generated, the ANProgram compiling preparer 1 28 appends it to the ANProgram 

code 202. Then, the ANProgram compiling preparer generates a message that the ANProgram 200 has been prepared 
for compiling by the server computer 104. 

The OrigParty then issues with the user interface 112 a command to the network communications manager 120 
to transmit the ANProgram 200 to the server computer 104, along with arguments specifying the architecture specific 

io language into which the program is to be compiled (ASLanguage ID) and the compiler to be used (Compiler ID). The 
network communications manager retrieves the ANProgram from the trusted or untrusted object class repository 140 
or 142 in which it is located and provides it to the network communications interface 116. The network communications 
manager then instructs the network communications interface to transmit the ANProgram to the server computer along 
with the specific arguments. 

75 

Compiling an Architecture Neutral Program 

The transmitted ANProgram 200 is then received at the server computer 104. The server computer includes a 
CPU 150, a user interface 152, a memory 154, and a network communications interface 156. The network communi- 

20 cations interface enables the server computer to communicate with the client computers 102 and the trusted key re- 
pository 106 via the network communications connection 108. 

The memory 1 54 of the server computer 1 04 stores an operating system 1 58, a network communications manager 
160, an ANProgram compiler 162, a signature verifier 164, an ANProgram integrity verifier 166, a signature generator 
168, an ANProgram repository 170, and an ASProgram repository 172. The operating system is run on the CPU 150 

25 and controls and coordinates running the programs 160-168 on the CPU in response to commands issued by a com- 
piling party (CompParty) with the user interface 1 52. 

The network communications interface 156 receives the ANProgram 200 and instructs the network communica- 
tions manager 160 that this has occurred. In response, network communications manager places the received ANPro- 
gram in the ANProgram repository 170. It the server 104 is set up as an automatic compiler service, this is done 

30 automatically by the network communications manager 160. Otherwise, the ANProgram is moved into repository 170 
by the network communications manager when the CompParty issues a command with the user interface. 

Then, either automatically, or upon the issuance of a command by the CompParty with the user interface 252, the 
ANProgram compiler 162 is invoked to compile the ANProgram 200. Table 2 contains a pseudocode representation 
of the compilation procedure used by the ANProgram compiler to compile the ANProgram. 

35 Referring to Figs. 1-2 and Table 2, the ANProgram compiler 162 first calls the signature verifier 164 to verify the 

DigitalSignature OP 210 in the received ANProgram 200 so as to establish that the DigitalSignature OP 210 is actually 
the originating party's signature for the ANProgram (e.g., as opposed to being a forged signature or the OrigParty 
signature on some other version of the ANProgram). In particular, the signature verifier uses the ClearText OrigParty's 
ID 216 in the received ANProgram to obtain the OrigParty's PublicKey from the trusted key repository 106. Then the 

40 signature verifier decrypts the encrypted MD OP 212 and HashFunction OP ID 214 in the DigitalSignature OP using the 
public encryption key of the OrigParty (OrigParty's PublicKey). 

Next, the signature verifier 164 generates a test message digest (TestMD op ), which should match the decrypted 
MD OP 21 2, by computing the corresponding HashFunction OP on the ANProgram code 202 of the received ANProgram 
200. The HashFunction OP ID 214 in the decrypted DigitalSignature OP is used to identify the proper HashFunction OP 

45 to be used. The decrypted MD OP and the generated TestMD OP are then compared to verify the DigitalSignature OP 21 0. 

If the MD OP 212 and the TestMD OP do not match, then the signature verifier 162 sends back a failed result to the 
ANProgram compiler 162. In response, the ANProgram compiler aborts the compiling procedure and generates an 
appropriate message. 

On the other hand, if the MD OP and the TestMD OP do match, then the signature verifier 162 sends back a passed 
50 result to the ANProgram compiler 162 and the ANProgram compiler calls the ANProgram integrity verifier 166. It in- 
structs the ANProgram integrity verifier to verify the integrity of the ANProgram code 202 of the received ANProgram 
200. This is done in the same manner and for the same purpose as was described earlier in the section discussing 
preparing the ANProgram for compiling. Thus, if the ANProgram code does not satisfy the predefined integrity criteria, 
the ANProgram int grity verifi r sends back a fail d result to the ANProgram compiler. In respons , th ANProgram 
55 compiler aborts the compiling procedur and gen rates an appropriate messag indicating this. 

Howev r, if the ANProgram code 202 of th rec ived ANProgram 200 do s satisfy th predefined int grity criteria, 
then the ANProgram integrity verifier 1 66 s nds back a passed result to the ANProgram compiler 1 62. The ANProgram 
compiler then compil s the ANProgram code into the ASLanguage identified by the ASLanguag ID specified by the 
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£ n ? ?7e» 9S 1 Tab ' e 2 ' ,hS C ° mpiler P ' aCeS ,he ANPro 9 ram °ode 202, the DigitalSignature OP 

tk A K!o° mP ASPr °9 ram code 302 in an ASProgram 300 that is stored in the ASProgram repository 172 
The ANProgram compiler 162 then calls the signature generator 168 and instructs it to generate the ANProgram 
SSfi*' 9 , f hTmo 6 (Di 9 i,alSi 9 nature c) 320 which can be verified to ensure that the ASProgram 300 was com- 
n nilS f trusted ANProgram compiler. This is done in a manner similar to that described earlier for generating the 
D,g.talSignature OP . However, in this case, the set of information signed is the ASProgram code and the DigrtalSigna- 
ure OP . Another predetermined hash function with a corresponding HashFunctioric ID 324 may be used to generate 
the message , digest MD C 322 of the set of information to be signed by the DigrtaTsignature c , L private enc^p fon 

STmp 0 ^ (C ° mpi,er ' S PriVat6Key) " USSd 10 enc W the MD C and th e C HashFunction c K 
HashFunSn tL^^T a^Z {Com 0 ,,6r ' s ID > is added in clear text at the end of the encrypted MD C and 
HashFunct.on c . The Compter's PrivateKey and ID are provided by the ANProgram compiler 

cin COmpNer 1 62 CaMS th6 Si9na,Ure 9 enerator 1 68 a second time to generate the CompParty's digital 

« !h hwTh^' 9 f ^ natUfeCp) 312 ' WhiCh C3n bG Verified by end users t0 ensure tnat tne ASProgram 300 was gener- 
nltnr» y , T CompParty. This is done in a similar manner to that described earlier for generating the DigtlalSig- 
nature 0 p (in the sect.on d.scussing preparing an ANProgram for compiling). However, here the message digest (MD C p) 
314 generated for the D.g,talSignature CP is generated by computing a predetermined or selected hash function (Hash- 
HashFuSLn" ? bitS ° f 'I 16 , ASPr °9 ram code - the Digita^ignatuerop and the DigitalSignature c . Similar to the 
for ST ! purpos , es ° f th ' S disclosure ' the HashFunction CP corresponds to the CompParty sfnce it was used 

for the DigrtalSignature CP of the CompParty. 

T >!!!? natUre genera,or 168 then encr VP ts ,he MD CP 314 and the ID of the HashFunction CP (HashFunction rp ID) 
the ilnti S ZTT? t y ° f Com P Part y (CompParty's PrivateKey). The signature generator then adds 
,h n , ,c C ° mpPa ? y ( c °™PPa"ys 'D) 318 in clear text at the end of the encrypted items 314 and 316 to 
Interface °^ 312 ' The CompParty's PrivateKey and ID are provided by the CompParty with the user 

n«nH?th the t Di f f a ' S < i9 na,ure c 320 and the DigitalSignature CP 312 are generated, the ANProgram compiler 162 ap- 
componlnTs In ASPr ° 9ram C ° dS 3 ° 2, S ° that ,he resultin 9 com P iled ASProgram file or object has the following 



ANProgram Code, 
DigitalSignature op , 
ASProgram Code, 
DigitalSignature c , and 
DigitalSignature cp 



Then, the ANProgram compiler generates a message that the ANProgram 200 has been compiled to form the ASPro- 
gram 300 and is ready to be sent to the OrigParty. 

The CompParty then uses the network communications manager 1 60 to transmit the ASProgram 300 to the Oria- 
Party s chent computer 102. The network communications manager does so by retrieving the ASProgram from the 
ASProgram repository 172 in which it is located and provides it to the network communications interface 156 The 

^n^J^TT^ mana9er ** m inStmCtS the netWOrk com ™nications interface to transmit the ASProgram to 
the OrigParty's client computer. a 

Object and Object Class Creation and Distribution 

The transmitted ASProgram 300 is then received by the communications interface 116 of the OrigParty's client 
computer and instructs the network communications manager 120 that this has occurred. In response the OrigParty 
issues a command with the user interface 252 to instruct the network communications manager to retrieve the received 
ASProgram from the network communications interface, causing the network communications manager to place the 
received ASProgram in the untrusted object class repository 142 of the OrigParty's client computer. Once this is done 
1 ! lQ T V 1 rSCeiVed ASPr °9 ram as a "ew object class with just one method (i.e. the compiled program 

cod ), or rt may create an object class that includes the ASProgram 300 as well as other ANPrograms and ASProqrams 

F,g. 4 shows a typical object class 400 in accordance with the present invention. The object class may include one 
or more ASPrograms 402 and/or one or more ANPrograms 404, as well as a virtual function table 410 For each 
ASProgram the virtual function table contains a corresponding identifier (native.ASProgram ID) 412 that indicates 
hat it is an ASProgram (i.e., a native program) that is not in the ANLanguage and a corresponding pointer (Ptr) 414 
to the nafve program. Similarly, for each ANProgram. th virtual function table contains a corr spending id ntifier 

in OS 3 !! ? Ito^ f correspondin 9 P° inter 41 8 10 the ANProgram. Every object 420 of this object class includes 
an object header 422 that points to the object class 400. 
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Thus, the OrigParty may create an object 420 and an object class 400 with the ASProgram 300 that was received 
from the server computer 104 as one of the ASPrograms 402 in the object class. 

When the OrigParty wishes to distribute to various ExecuteParties an object and object class that includes the 
ASProgram 300 and ANProgram, then the OrigParty issues a command with the user interlace 112 to instruct the 
network communications manager to transmit these items to the client computer 1 02 of the ExecuteParties. The network 
communications manager does this by retrieving them from the untrusted object class repository 142 in which they are 
located and provides them to the network communications interface 116 with appropriate transmission instructions. 
Alternately, the network communications manager of the OrigParty may respond to a request initiated by an Exe- 
cuteParty for a copy of a specified object class 400. 

Execution of Architecture Neutral Programs and Architecture Specific Programs in an Object Class 



The network communications interface 156 of the client computer 102 receives the transmitted object and object 
class and instructs the network communications manager 160 that this has occurred. In response, the ExecuteParty 

is issues a command with the user interface 11 2 to instruct the network communications manager to retrieve the received 
object and object class irom the network communications interface. The network communications manager then stores 
the received object and object class in the untrusted object class repository 142. 

The untrusted object class repository 142 of each client computer 102 contains the objects and their associated 
object classes that are not trusted. These object classes are not trusted because any ANPrograms they include have 

20 not yet had their inlegnly vended and any ASPrograms they include have not had their source verified nor have been 
verified as being compiled fiom the proper ANProgram. 

The trusted object class repository 140 of each client computer contains the objects and their object classes that 
are trusted. These object classes are trusted because any ANPrograms they include may have already had their 
integrity verified by the ANProgram integrity verifier 136 and any ASPrograms they contain have been ascertained to 

2S be trustworthy. In fact : some or all the object classes in the trusted object class repository 140 need not have digital 
signatures, because these object classes are trusted and therefore there is no reason to perform integrity checks on 
the methods in these object classes. 

It is desirable to have an object class that primarily includes ANPrograms but may also include ASPrograms so 
that essentially all legitimate tasks can be performed with the object class, as suggested earlier. Therefore, the AN- 

30 Program executer 1 22 is capable of executing integrity verifiable ANPrograms and calling the ASProgram executer to 
execute integrity non-verifiable ASPrograms that are either (1) in trusted object classes in the trusted object class 
repository 1 40, or (2) that are in untrusted object classes in the untrusted object class repository 1 42 and have verifiable 
DigitalSignature OP , DigitalSignature CP and DigitalSignature c information so that essentially all legitimate tasks can be 
performed. In this way, ASPrograms of untrusted object classes that donl have DigitalSignature OP , DigitalSignature CP 

35 and DigitalSignature c information or whose digital signatures cannot be verified are prevented from being executed. 
Table 3 contains a pseudocode representation of the execution procedure used by the ANProgram executer. 

Referring to Figs. 1-4 and Table 3, at the client computer 102 of an ExecuteParty (e.g., the OrigParty or another 
party), the ANProgram executer 124 may be executing an ANProgram that seeks to call a method in a specified object 
class. The method call is initially handled by the object class loader 136, which determines whether or not the object 

to class has already been loaded. If the object class has already been loaded into the ExecuteParty's user address space 
138, then the ANProgram executer 122 executes the called method if the called method is an ANProgram and the 
ASProgram executer 124 executes the called method if the called method is an ASProgram. 

However, if the object class has not yet been loaded into the ExecuteParty's address space 138, then the object 
class loader 1 36 loads the object class into the ExecuterParty's address space and determines whether or not execution 

45 of the called method is to be allowed. For instance, if the object class was loaded from the trusted object class repository 
140, then execution of the called method is permitted and the Execute procedure is called. The Execute procedure 
(see Table 3) calls the ANProgram executer if the called method is an ANProgram, and otherwise calls the ASProgram 
x cuter 1 24 to execute the called method. 

However, if the object class was loaded from the untrusted object class repository 142, the class loader 136 ex- 

50 amines the object header of the object to determine if its object class includes any ASPrograms. It does so by deter- 
mining if there any native_ASProgram IDs in the virtual function table of the object. 

If there are no ASPrograms in the object class, then the class loader 136 calls the ANProgram integrity verifier 
136 to v rify th integrity of the ANPrograms in the object class. This is done in the same manner and for the same 
purpose as was described earlier for verifying the integrity of th ANProgram 200 (in the section discussing compiling 

55 an ANProgram). Thus, if the integrity of any of the ANPrograms is not verifi d, th n the ANProgram int grity v rifier 
passes back to the class loader a failed result and the class loader aborts the class loading procedur and generates 
an appropriate message indicating this. But, if th ANProgram integrity verifier sends back a passed result indicating 
that all of the ANPrograms of the object class are verified, the class loader enables execution of th called method. 
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ihp ^ ^ S n r ° 9 T S 0bjeC, Cl8SS ' ,h6n ,he ClaSS ,oader 1 36 calls the si 9 na ture verifier 1 32 to verily 

S , h n™ D,grta.S,gnature c and the CompParly signature DigitalSigna1ur ecp . If any of the ASPrograms 

JS^^L^£Sl^^ , ^ ,0n ? UracR ^ 8 Di 9 ita,Si 9 nature c the integrity o, the ASProgram's source cannot be 
.verified and therefore the s.gnature verifier sends back to the ANProgram executer a failed result In response the 

fSSZ ifSVST t!? C,3SS ,0adin9 Pr ° CedUre 9enerateS an appr ° priate messa9e tnat this nJsTuVed 
H Bn So « f .1 r d ASProsrams In the ob ) ect class do include a DigitaSignature CP and a DigitalSignature c . the 
t ,h " C ° m P Rart y and the Compiler as indicated in these two digital signatures, are compared with the lists 

1 44 (see Fig. 1 ) of known, trusted Compiler Parties and trusted Compilers. If any of the ASPrograms in the ob^ct class 
were compiled by a CompParty or a Compiler not included in the set of known trusted Compi.eTpartTes and t uSd 
Compi ers. » he Cass loading procedure is aborted, and execution of the called method is thereby b^ked Sim 
the ASLanguage identified ,n any of the ASPrograms does not match the ASLanguage used by the ASProqram Exe- 
cuter 124. the class loading procedure is aborted. *«J oy me /torrogram bxe 

the idenm,>H 'i'l?,! ASP /° 9rams in the object class do include a DigitalSignaturecp and a DigitalSignature c , and 
the identified CompParty and Compiler for all the ASPrograms are trusted Compiler Parties and Compilers and the 

J2L7l3 u ri?l? e ASPr ° 9ramS iS ° ne USed * the ASPraQram E — ter, then the signature veS ve'if es 
these signatures in a similar manner as was described earlier for verifying the DigrtalDignatureop (in the section dis- 
cussing compiling the ANProgram 200). However, in this case, the Compiler's and CompParty? pub ic keys are e- 
tneved I from the trusted key reposttory 106 and respectively used to decnypt the MD C and ^fCLSTd In i. 

ZVt! !&" T *~ HaSh ?™«™c P - in the D ig ita,Signature CP .furthermore, the teSmessag 
rnnf ( f h h f k, f u CP) corres P° ndln g «° »» decrypted MD CP and MD C are generated by computing hash 
J^dSS^uS f 6 l SP T 9 rn COde P ' US D ^ S ^*o P for theTestMDe and on L same da'ta bfts 
S fed S! thl 9 l 9 , h u C Z: TestMD ^' accordin 9 respective* to the HashFunction c and HashFunction CP iden- 
tified by the decrypted HashFunction c ID and HashFunction cp ID 

for JIl™ °J; ta ' Signat ": e c ***** the DigitalSignature cp is not verified (i.e., MD C # TestMD c and/or MD CP # TestMD CP ) 
Z 22 ^7° 9 Trl I 6 " ■ * S ', 9na,Ure VeHfier 1 36 SendS baCk 10 the C,ass ,oader 1 36 a ,ai '^ resutt In response 

HowJvIr tf?h ^ ^ S l08din9 Pr ° CedUre 9enera,eS an a PP r °P ria ^ m— ag. that this has occurred. 
T«tl£ M D, 9' ,alS '9 na,u ^c and the DigitalSignature CP are both verified (i.e., MD C = TestMD c and MD CP = 

TestMDcp) for every ASProgram, then the ANProgram executer 124 again calls signature verifier 132 to verify the 
SbS^ZST (Di t 9itaSi 9 na, " re - ) f ° r the ANProaram. from which the ASPrograms were compiled. To verify 
he OngParty digital Signatures, the DigitalSignature OP of each is verified in the same manner as was discussed ear J 
in the section concerning compilation of the ANProgram 200 

the ^^^S^SSp ^ of f the ANPr ° gramS f rom which ,he ASPrograms were compiled is verged, then 
Hp AMPrL ^ ANProgram mtegrrty venfier to verify the integrity of every ANProgram in the object class and 
H£??JS 1? r , ° h Tt ASPr ° 9rams were com P» ed - ™. is done in the same manner as was described 
t h e dL l T^Z% °h 1 th ! S ! ' ANPr ° 9rams is ** veri «* d . -en the ANProgram integrity verffier sends back to 
the class loader a failed result. wh,ch aborts the class loading procedure and generates an appropriate message 

However if the integrity of each of the ANPrograms is verified, then the ANProgram integrity verifier 1 26 sends 
backa passed resutt to the class loader 136. In response, the Cass .oader invokes The ANpSTSLSoTS 
Program executer to execute the called method, as appropriate. «*ecuier or ms. 

In view of the foregoing, the ExecuterParty is assured that only those untrusted object classes in the untrusted 

h T h T- inte9ri,y Verifiab ' e ANPr °9 rams ™« ASPrograms whose digital signatures can b vSEJS 
be loaded and have their programs executed. 1 



Alternative Embodiments 



th»t flS^J? 'TT* ° 1 inVen,i ° n described above are °P«°na'- Thus, those skilled in the art will recognize 
that alternative embodiments exist that don't include these features. ^cognize 

Sinner 3 " 1 "' 6 ' ^ Ar ? Pr ° 9ram com P iler h^ been described as generating both a DigitalSignature cp and a Digital. 
in S ll C H reSP TT ' C ° m P Part y and fte ANProgram compiler. However, the ANProgram compiler coufd be 

^^S^S^aS^ ° nly .° ne ° f th6Se di9ite ' Si9na,UreS ,0f 6nablin9 VSrifica,ion of the eithe ' lhe 
us d to compile the ASProgram or the compiling party. 

DiaiSsiSu^ H° 9ram e 1! CU,er bSen d8SCribed 88 reqUlrin9 verifica, ion of both a DigitalSignature CP and a 
S S % f C ! ' Pr ° 9ram eXSCU,er COU ' d be construc ted to require verification of only one of thes 

«g tal signatures and optionally verify th other digital signature if the ASProgram being verified includes it Further- 
mor th program executer could be constructed to skip the step of verifying the int grity of the ANProgram corre- 
^T' baS6d ° n ,hS aSSUmpti ° n ,h3t the C ° mpilin9 part * is ^'ed'and that tt is a'dufy "the 
compLatfo! T V m,e9 ' ° f SaCh ANPr ° 9ram ,hat is '"to an ASProgram prior to performing the 
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When the ExecuterParty is the OrigParty, the ExecuterParty knows that it actually sent the ANProgram 200 to th 
CompParty's server computer 1 04 to be compiled into the ASProgram 300. In this case, the class loader 1 36 could be 
constructed to not call the signature verifier to verify the DigtialSignature OP in the ANProgram. Rather, the Executer- 
Party can simply compare the DigtialSignature OP in the local copy of the ANProgram with the DigtialSignature OP in 
the compiled ASProgram. Additionally, the class loader could be constructed to not call the ANProgram integrity verifier 
1 26 to verify the integrity of the ANProgram corresponding to a called ASProgram since the integrity of the ANProgram 
would have been checked during the preparation for compiling procedure prior to being sent to the compiling server 
computer. Alternatively, the ANProgram compiling preparer 1 28 could be constructed to not call the ANProgram integrity 
verifier during the preparation for compiling procedure since its integrity would be checked both by the compiler and 
when the class loader calls the ANProgram integrity verifier prior to execution of the corresponding ASProgram. 

TABLE 1 

Pseudocode Representation of Method of Preparing Architecture 
Neutral Program for Compiling 

Procedure: Prepare for Compiling (ANProgram code, OrigParty's PrivateKey, and 
OrigParty's ID) 
{ 

Verify integrity of ANProgram with ANProgram integrity verifier 
If failed result 

{ abort and generate failed result message } 
Generate MD OP = HashFunction OP (ANProgram code) 

Generate DigitalSignature 0P = Encrypt (MD op + HashFunction op ID, OrigParty's 

PrivateKey) + ClearText (OrigParty's ID) 
Append DigitalSignature op to ANProgram code 
Generate message that ANProgram is prepared for compiling 
Return 
} 
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TABLE 2 

Pseudocode Representation of Method of Compiling ANProgram and 
Generating ASProgram 

Procedure: Compile (ANProgram, CompParty's ID. ASLanguagelD. CompParty's 
PrivateKey, Compiler's ID, and Compiler's PrivateKey) 
{ 

Retrieve OrigParty's PublicKey from trusted key repository using ClearText 

OrigParty's ID in DigrtalSignature op 
Decrypt (MD OP + HashFunctionop ID in DigitalSignature OP , OrigParty's 

PublicKey) 

Generate TestMD op = HashFunctionop (ANProgram code) using 
HashFunction OP identified by decrypted HashFunction OP ID 

Compare decrypted MD OP and TestMDop 

If decrypted MD OP * TestMD OP 
{ 

r DigitalSignature OP of OrigParty not verified 7 

Generate failed result message 

} 

Else 

{ 

r DigitalSignature 0P of OrigParty has been verified 7 
Verify integrity of ANProgram with ANProgram integrity verifier 
If failed result 

{ 

abort and generate failed result message 
} 

Else 

{ 

I* ANProgram has been verified 7 

Compile ANProgram code into ASLanguage identified by 

ASLanguage ID to generate ASProgram code 
Generate MD C = HashFunctioncs (ASProgram code + 

DigitalSignature 0P ) 
Generate DigitalSignature c = Encrypt (MD C + HashFunction c ID. 

ANProgrom Compiler's PrivateKey) + ClearText 

ANProgram Compiler's ID 
Generate MD CP = HashFunctionc, (ASProgram code + 

DigrtalSignatureop + DigitalSignature c ) 
Generate DigitalSignature cp = Encrypt (MD CP + HashFunction CP 

ID. CompParty's PrivateKey) + ClearText CompParty's ID 
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Generate and Return File or Object containing: 

ANProgram Code, 

DigitalSignature OP , 

ASProgram Code, 

DigitalSignature c , and 

DigitalSignature CP 
/* ASProgram has been compiled and generated 
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TABLE 3 



Pseudocode Representation of Method of Executing 
Architecture Specific Program 

Procedure: Execute (ObjectClass, Program) 
{ 

If the Program is a verifiable program 

{ Execute Program using the Bytecode Interpreter } 
Else 

{ Execute Program using the compiled program executer } 

} 

Procedure: ClassLoad (ObjectClass, Program) 
{ 

If Object Class has already been loaded into ExecuterPart/s address space 

Call Execute (ObjectClass, Program) 
Return 

} - 

I* The Object Class has not been loaded V 

Load Object Class into ExecuterParty*s address space 

If Object Class was loaded from Trusted Object Class Repository 

Call Execute (ObjectClass, Program) 
Return 

} 

r Object Class was loaded from Untrusted Object Class Repository */ 
If Object Class does not contain any ASPrograms designated as 
native_ASPrograms in Object Header of Object 

{ 

Verify integrity of all ANPrograms of Object Class with ANProgram integrity 

verifier 
If failed result 

{ 

Abort with appropriate failed result message 
} 

Else 

r Integrity of all ANPrograms of Object Class have been verified V 
{ Call Execute (ObjectClass, Program) } 



12 



EP 0 778 520 A2 



10 



15 



25 



30 



35 



40 



45 



SO 



Return 
} 

t* Object Class does contain ASPrograms designated as native_ASPrograms in 

Object Header of Object */ 
If any ASProgram does not contain a DigitalSignature CP and a DigitalSignature c 

{ 

r Compiling Party and Compiler of every ASProgram cannot be verified */ 

Generate appropriate message 

Return 

} 



For each ASProgram in Object Class: 

{ Determine identity of CompParty and Compiler and determine 
20 ASLanguage used by ASProgram } 

If identity of CompParty for any ASProgram is not a known, trusted, Compiling 
Party, or the identity of Compiler is not a known, trusted Compiler, or the 
identified ASLanguage is not one used by the ASProgram Executer 
{ 

Generate appropriate message 
Return 
} 



ss 



For each ASProgram in Object Class: 
{ 

Retrieve CompParty's PublicKey from trusted key repository using ClearText 

CompParty's ID in DigitalSignaturecp 
Decrypt (MD^ + HashFunctioncp ID in DigitalSignature CP , CompParty's 

PublicKey) 

Generate TestMD CP = HashFunction CP (ASProgram code + DigitalSignature OP 
+ DigitalSignature c in ASProgram) using HashFunction cp identified by 
decrypted HashFunction CP ID 

Compare decrypted MD^ and TestMD cp 

} 

If decrypted MD CP * TestMD CP for any ASProgram 
{ 

/* DigitalSignature CP for every ASProgram has not been verified */ 

Generate appropriate failed result message 

Return 

} 

/* Digita!Signature CP for every ASProgram has been verified*/ 
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For each ASProgram in Object Class: 
{ 

Retrieve ANProgram Compiler's PublicKey from trusted key repository using 
ClearText ANProgram Compiler's ID in DigitalSignature c 

Decrypt (MD C + HashFunction c ID in DigitalSignature c . ANProgram 
Compiler's PublicKey) 

Generate TestMD c = HashFunction c (ASProgram code + DigitalSignature op ) 
using HashFunction c identified by decrypted HashFunction c ID 

Compare decrypted MD C and TestMD c 

} 

If decrypted MD C * TestMD c for any ASProgram 
{ 

r DigitalSignature c for every ASProgram in Object Class has not been 
verified */ 

Generate appropriate failed result message 
Return 

} 

I* DigitalSignature c for every ASProgram in Object Class has been verified */ 
For each ANProgram from which an ASProgram in Object Class was compiled: 

Retrieve OrigParty's PublicKey from trusted key repository using ClearText 

OrigParty's ID in DigitalSignature 0P 
Decrypt (MD^ + HashFunction OP ID in DigitalSignature OP , OrigParty's 

PublicKey) 

Generate TestMD OP = HashFunction OP (ANProgram code) using 
HashFunction op identified by decrypted HashFunction op ID 
Compare decrypted MD 0P and TestMD OP 

If decrypted MDop * Test,MD 0P for any ANProgram 

r DigitalSignature op for every ANProgram from which an ASProgram in 

Object Class was compiled not verified */ 
Generate failed result message 
Return 
} 

r The DigitaIS«gnature 0P in every ASProgram in Object Class is verified V 

Venfy integrity of ANPrograms in Object class and ANPrograms from which 

ASPrograms in Object Class were compiled with ANProgram integrity verifier 
If failed result 

{ 
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Generate failed result message 
Return 

} 

r Integrity of all ANPrograms in Object class and all ANPrograms from which 
ASPrograms in Object Class were compiled have been verified */ 
w Call Execute (ObjectClass, Program) 

} 



is Claims 

1. A computer comprising: 

a program integrity verifier that verifies that programs written in an architecture neutral language satisfy pre- 
20 defined program integrity criteria; 

a digital signature verifier that verifies the digital signatures of originating parties of programs that are contained 
in the programs; 

an untrusted object class repository that stores untrusted object classes; 

a trusted object class repository that stores trusted object classes; 
25 said object classes each including at least one program, each program comprising a program selected from 

the group consisting of (A) architecture neutral programs written in the architecture neutral language and (B) 

architecture specific programs written in an architecture specific language whose integrity cannot be verified 

by the integrity verifier; 

an architecture specific program executer; 
30 an architecture neutral program executer; 

a user address space; and 

a class loader that loads a specified one of said object classes into the user address space for execution when 
execution of any program in the one object class is requested, said class loader including program security 
logic 1or preventing the loading of any requested object class, other than object classes in said trusted object 
35 class repository, that includes at least one architecture specific program unless every architecture specific 

program in the requested object class includes a digital signature and said digital signature is successfully 
verified by said digital signature verifier. 

2. The computer of claim 1 , said class loader includes verifier logic for invoking said program integrity verifier to verify 
40 the integrity of every architecture neutral program in the requested object class when the requested object class 

is not stored in said trusted object class repository and includes at least one architecture neutral program; 

said program security logic further preventing the loading of said any requested object class other than object 
classes in said trusted object class repository when the requested object class includes at least one architecture 
neutral program whose integrity is not verified by said program integrity verifier. 



45 



3. The computer of claim 1, 



each said digital signature associated with one of said architecture specific programs including a signing party 
identifier and an encrypted message, said encrypted message including a message digest of the architecture 

50 specific program generated using a message digest function wherein said encrypted message has been en- 

crypted using a private encryption key associated with said identified signing party; and 
said digital signature verifier including logic for processing a specified digital signature by obtaining a public 
key associated with the signing party identified by said signing party identifier, decrypting the encrypted mes- 
sag of said digital signature with said public key so as generat a decrypted message digest, generating a 

55 testmessag digest by executing said message digest function on th architectur specific program associat d 

with said digital signature, comparing said test message digest with said decrypted m ssage digest, and is- 
suing a failure signal if said decrypted message digest and test message digest do not match. 
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4. The computer of claim 1 , 

said program security logic further for preventing the loading of any requested object class, other than object 
classes in said trusted object class repository, that includes at least one architecture specific program unless 
every architecture specific program in the requested object class includes two digital signatures and said digital 
signatures are both successfully verified by said digital signature verifier; 

each said digital signature associated with one of said architecture specific programs including a signing party 
identifier and an encrypted message, said encrypted message including a message generated by a predefined 
procedure, wherein said encrypted message has been encrypted using a private encryption key associated 
with said identified signing party; 

said digital signature verifier including logic for processing a specified digital signature by obtaining a public 
key associated with the signing party identified by said signing party identifier, decrypting the encrypted mes- 
sage of said digital signature with said public key so as generate a decrypted message, generating a test 
message by executing said predefined procedure on the architecture specific program associated with said 
digital signature, comparing said test message with said decrypted message, and issuing a failure signal if 
said decrypted message digest and test message digest do not match; and 

said program security logic preventing loading of the requested object class, other than object classes in said 
trusted object class repository, unless every architecture specific program in the requested object class in- 
cludes a first digital signature for which the signing party is a member of a first group of trusted parties, and 
includes a second digital signature for which the signing party is a member of a second group of trusted parties. 

5. The computer of claim 1 , 
said program security logic preventing loading of the requested object class, other than object classes in 

said trusted object class repository, unless every architecture specific program in the requested object class in- 
cludes a message digest for an associated architecture neutral program, and said message digest matches a test 
message digest generated by said program security logic by performing a predefined message digest procedure 
on said associated architecture neutral program. 

6. A method of operating a computer system, comprising the steps of: 

storing untrusted object classes in an untrusted object class repository; 
storing trusted object classes in a trusted object class repository; 

said object classes each including at least one program, each program comprising a program selected from 
the group consisting of (A) architecture neutral programs written in an architecture neutral language and (B) 
55 architecture specific programs written in an architecture specific language; 

when execution of any program in the one object class is requested, loading the requested object class into 
a user address space for execution unless loading of the requested object class is prevented by a security 
violation, including preventing the loading of any requested object class, other than object classes in said 
trusted object class repository, that includes at least one architecture specific program unless every architec- 
ture specific program in the requested object class includes a digital signature and said digital signature is 
successfully verified by said digital signature verifier. 
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7. The method of claim 6, said object class loading step including (A) verifying the integrity of every architecture 
neutral program in the requested object class when the requested object class is not stored in said trusted object 

*s class repository and includes at least one architecture neutral program, and (B) and preventing the loading of the 

requested object class, unless the requested object class is in said trusted object class repository, when the re- 
quested object class includes at least one architecture neutral program whose integrity is not verified. 

8. The method of claim 6, 

so 

each said digital signature associated with one of said architecture specific programs including a signing party 
identifier and an encrypted message, said encrypted message including a message digest of the architecture 
specific program generated using a message digest function wherein said encrypted message has been en- 
crypted using a private encryption key associat d with said identified signing party; and 
SS said ob i ect c,ass loading step including processing a specified digital signatur by obtaining a public key as- 

sociated with the signing party identified by said signing party identifier, decrypting the encrypted messag of 
said digital signature with said public key so as generate a decrypted message digest, generating a test mes- 
sage digest by executing said m ssage digest function on th architecture specific program associated with 
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said digital signature, comparing said test message digest with said decrypted message digest, and issuing 
a failure signal if said decrypted message digest and test message digest do not match. 

9. The method of claim 6, 

5 

object class loading step including preventing the loading of any requested object class, other than object 
classes in said trusted object class repository, that includes at least one architecture specific program unless 
every architecture specific program in the requested object class includes two digital signatures and said digital 
signatures are both successfully verified by said digital signature verifier; 
io each said digital signature associated with one of said architecture specific programs including a signing party 

identifier and an encrypted message, said encrypted message including a message generated by a predefined 
procedure, wherein said encrypted message has been encrypted using a private encryption key associated 
with said identified signing party; 

said object class loading step including processing a specified digital signature by obtaining a public key as- 
is sociated with the signing party identified by said signing party identifier, decrypting the encrypted message of 

said digital signature with said public key so as generate a decrypted message, generating a test message 
by executing said predefined procedure on the architecture specific program associated with said digital sig- 
nature, comparing said test message with said decrypted message, and issuing a failure signal if said decrypt- 
ed message digest and test message digest do not match. 
20 said object class loading step further including preventing loading of the requested object class, other than 

object classes in said trusted object class repository, unless every architecture specific program in the request- 
ed object class includes a first digital signature for which the signing party is a member of a first group of 
trusted parties, and includes a second digital signature for which the signing party is a member of a second 
group of trusted parties. 

2$ 

10. The method of claim 6, 

said object class loading step including preventing loading of the requested object class, other than object 
classes in said trusted object class repository, unless every architecture specific program in the requested object 
class includes a message digest for an associated architecture neutral program, and said message digest matches 
30 a test message digest generated by said program security logic by performing a predefined message digest pro- 

cedure on said associated architecture neutral program. 

11. A memory for storing data programs being executed on a data processing system, said memory comprising: 

35 a program integrity verifier that verifies that programs written in an architecture neutral language satisfy pre- 

defined program integrity criteria; 

a digital signature verifier that verifies the digital signatures of originating parties of programs that are contained 
in the programs; 

an untrusted object class repository that stores untrusted object classes; 

40 a trusted object class repository that stores trusted object classes; 

said object classes each including at least one program, each program comprising a program selected from 
the group consisting of (A) architecture neutral programs written in the architecture neutral language and (B) 
architecture specific programs written in an architecture specific language whose integrity cannot be verified 
by the integrity verifier; 

45 an architecture specific program executer; 

an architecture neutral program executer; and 

a class loader that loads a specified one of said object classes into a user address space for execution when 
execution of any program in the one object class is requested, said class loader including program security 
instructions for preventing the loading of any requested object class, other than object classes in said trusted 
bo object class repository, that includes at least one architecture specific program unless every architecture spe- 

cific program in the requested object class includes a digital signature and said digital signature is successfully 
verified by said digital signature verifier. 

12. Th memory of claim 11 , said class loader includes v rifi r instructions for invoking said program integrity verifier 
55 to verify th integrity of ev ry archit cture neutral program in the request d object class when th requested object 

class is not stored in said trusted object class r pository and includes at least one architecture n utral program; 

said program security instructions further preventing the loading of said any requested object class other 
than object classes in said trusted object class repository when the request d object class includes at least one 
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architecture neutral program whose integrity is not verified by said program integrity verifier. 
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(57) A computer system includes a program execut- 
er that executes verifiable architecture neutral programs 
and a class loader that prohibits the loading and execu- 
tion of non-verifiable programs unless (A) the non-veri- 
fiable program resides in a trusted repository of such 
programs, or (B) the non-verifiable program is indirectly 
verifiable by way of a digital signature on the non-veri- 
fiable program that proves the program was produced 
by a trusted source. In the preferred embodiment, veri- 
fiable architecture neutral programs are Java bytecode 
programs whose integrity is verified using a Java byte- 
code program verifier The non-verifiable programs are 
generally architecture specific compiled programs gen- 
erated with the assistance of a compiler. Each architec- 
ture specific program typically includes two signatures, 
including one by the compiling party and one by the 



compiler. Each digital signature includes a signing party 
identifier and an encrypted message. The encrypted 
message includes a message generated by a prede- 
fined procedure, and is encrypted using a private en- 
cryption key associated with the sighing party. A digital 
signature verifier used by the class loader includes logic 
for processing each digital signature by obtaining a pub- 
lic key associated with the signing party, decrypting the 
encrypted message of the digital signature with that 
public key so as generate a decrypted message, gen- 
erating a test message by executing the predefined pro- 
cedure on the architecture specific program associated 
with the digital signature, comparing the test message 
with the decrypted message, and issuing a failure signal 
if the decrypted message digest and test message di- 
gest do not match. 



CO 
< 

o 

CM 

in 

00 

1^ 
o 

LLI 

Printed by Jouve. 75001 PARIS (FR) 

4SDOCID: <EP 077B520A3J_> 



EP 0 778 520 A3 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 96 30 8582 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate, 
of relevant passages 



Relevant 
to claim 



CLASSIFICATION OF THE 
APPLICATION (lrrt.CI.6) 



EP 0 555 715 A (IBM) 18 August 1993 

* page 17, line 49 - page 18, line 34 * 

EP 0 328 232 A (FISCHER ADDISON M) 
16 August 1989 

* page 8, line 17 - page 9, line 27; 
figures 2,3 * 

VAN HOFF A: "Java and Internet 
programming" 

DR. DOBB'S JOURNAL, AUG. 1995, USA, 
vol. 20, no. 8, pages 56, 58, 60-61, 101 
- 102, XP000570180 
ISSN 1044-789X 

* page 58, 1 ine 12 - 1 ine 44 * 

GB 2 227 584 A (INT COMPUTERS LTD) 

1 August 1990 

* abstract * 

* page 3, line 11 - page 4, line 28 * 

EP 0 464 526 A (HEWLETT PACKARD CO) 
8 January 1992 

* page 2, line 1 - page 5, line 33 * 

* page 7, line 46 - page 9, line 7; figure 

2 * 



1-12 



1-12 



I, 2,6,7, 

II, 12 



G06F1/00 

G06F9/445 

G06F9/45 



1,6,11 



1,6,11 



TECHNICAL FIELDS 
SEARCHED <)nt.CU> 



G06F 

G06G 



The present search report has been drawn up tor all claims 



Pt»CB Of SMfCh 

THE HAGUE 



Date at completion cl the March 

4 February 1999 



Exxnvrw 

Bijn, K 



CATEGORY OF CITED DOCUMENTS 

X : particularly relevant If taken alone 

Y : particuJarty relevant 9 combined with another 

document of the same category 
A : technological background 
O : non-wrttten disclosure 
P : intermediate document 



T ; theory or prfncfile underlying tha invention 
E : sorter patent document, but published on, or 

after the Ring date 
D : document cited In the application 
L : document dted for other reasons 



4 : member of the same patent famOy. corresponding 
document 



2 



EP 0 778 520 A3 



ANNEX TO THE EUROPEAN SEARCH REPORT 
ON EUROPEAN PATENT APPLICATION NO. 



EP 96 30 8582 



This annex lists the patent lamiry members relating to the patent documents cited in the above-mentioned European search report 
The memt>ers are as contained in the European Patent Office EDP file on 

The European Patent Office is in no way liable for these particulars which are merely given for the purpose of information. 

04-02-1999 



Patent document 
cited in search report 



Publication 
date 



Patent family 
member(s) 



Publication 
date 



EP 


0555715 


A 


18-08-1993 


US 


5301231 A 


05-04-1994 










JP 


5334073 A 


17-12-1993 


EP 


0328232 


A 


16-08-1989 


US 


4868877 A 


19-09-1989 










AT 


122190 T 


15-05-1995 










AU 


2512488 A 


07-09-1989 










CA 


1331213 A 


02-08-1994 










DE 


68922422 D 


08-06-1995 










DE 


68922422 T 


07-09-1995 










ES 


2071651 T 


01-07-1995 










US 


5005200 A 


02-04-1991 










US 


5214702 A 


25-05-1993 


GB 


2227584 


A 


01-08-1990 


AU 


623214 B 


07-05-1992 










AU 


4879590 A 


02-08-1990 


EP 


0464526 


A 


08-01-1992 


US 


5280613 A 


18-01-1994 










DE 


69125755 D 


28-05-1997 










DE 


69125755 T 


18-09-1997 



uj For more details about this annex : see Official Journal of the European Patent Office. No. 12/82 



_0776520A3J_> 



THIS PAGE BLANK (usptoj 



